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1 INTRODUCTION 

This  document  describes  a preliminary  Implementation  scheme  for 
a sinrj  I e-connect  ion  internetuork  Transmission  Control  Program  ITCP] . It 
Is  designed  to  operate  on  a dedicated  small  computer  with  minimal 
operating  system  assistance  and  to  support  low  delay,  low  through-put 
interactive  traffic.  Although  assumed  to  be  attached  to  the  ARPANET  via 
a local  or  remote  host  Interface  Q),  only  minimal  changes  are 
necessary  for  connection  to  the  Packet  Radio  Network  using  the  Channel 
Access  Protoco I I2J . 

Detailed  knowledge  is  assumed  of  the  internetwork  TCP  protocol 
and  the  reader  is  referred  to  the  official  specification  13]  (4]  for 
justification  and  further  discussion  of  the  details  of  the  protocol. 

NOTE:  There  have  been  several  changes  to  the  protocol  that  are 
not  listed  in  the  December  1374  revision  (3).  Among  these,  addition  of 
the  Beginning  Of  Segment  [BOS]  bit  and  Timestamping  In  effect  IT]  bit  in 
the  control  information  word;  addition  of  a 32  bit  field  for 
timestamping  information  and  sending  an  Acknowledgement  for  FIN 
requests.  The  final  specification  will  be  available  by  February,  1976. 


2 DESCRIPTION  of  TCP  FUNCTIONS 

For  maximum  size  reduction,  only  the  single-connection  user 
subset  of  functions  are  implemented.  Unsupported  functions  are: 

1)  Unspecified  sockets  - On  doing  an  OPEN,  the  user 
must  fully  specify  the  destination  NET,  TCP  and  PORT 
socket  addresses,  eliminating  connections  analogous  to 
the  NCP  "listening"  connection  needed  only  by  server  and 
logger  processes.  (To  permit  a host  to  provide  service 
serially  through  a single  channel  TCP,  this  function  may 
be  implemented  leter.) 

2)  Re-assembly  of  fragmented  segments  - Packets 
must  have  both  the  Beginning  Of  Segment  IBOS]  and  End  Of 
Segment  [E0S3  control  bits  asserted.  If  not,  on  passing 
through  a gateway,  the  segment  was  broken  Into 
fragments;  it  should  be  discarded  without  processing. 

The  re-construction  of  segments  has  yet  to  be  resolved; 
but  it  can  be  avoided  by  limiting  segment  length  (by 
receive  window  size  control)  to  less  than  the  gateway 
fragmentation  threshold.  Though  In  the  future,  it  may 
become  necessary  to  implement  it, 

3)  ECHO  and  TRASH  special  functions  - Being  solely 
for  experimentation  purposes,  ECHO  and  TRASH  special 
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functions  are  not  implemented.  Messages  containing 
these  special  functions  are  ignored.  (If  the  cost 
penalty,  mainly  storage  capacity,  Is  not  too  high,  these 
functions  will  be  implemented  later.) 

4)  Timestamping  - The  timestamping  control  bit  is 
ignored  and  the  contents  of  the  returning  packet’s 
timestamp  field  will  be  undefined. 

5)  Parameter  change/Status  socket  - Being  strictly 
single-connection,  there  is  no  Parameter  change/Status 
socket.  (Note  - this  socket  is  distinct  from  the  Uell 
known  Socket  0. ) 

Except  for  these  rest  let  ions,  the  TCP  insures  end-to-end 
acknowledgement,  error  correction,  duplicate  detection,  sequencing  and 
flow  control;  providing  the  user  process  a reliable,  error-free  logical 
communications  channel. 


5 USER- TCP  INTERFACE 

Five  primitives  comprise  the  USER/TCP  interface.  It  is  intended 
that  these  routines  be  called  via  a subroutine  jump  or  supervisor  call 
and  indicate  command  acceptance  or  rejection  on  exit.  When  complete, 
the  user  will  be  notified  of  the  final  disposition  of  OPEN,  SEND  and 
CLOSE  requests.  This  allows  user  processing  to  proceed  asynchronously 
and  In  parallel  with  TCP  processing. 

1)  OPEN  CONNECTION  - Used  to  establish  a 
connection,  the  OPEN  primitive  is  passed  the  address  of 
the  foreign  and  local  socket  ids.  If  a connection 
already  exists,  the  OPEN  is  rejected  and  an  error 
returned  to  the  caller.  After  checking  the  request  and 
socket  ids,  the  control  variables  are  initialized  and  an 
Initial  Sequence  Number  (ISN)  is  chosen.  Since  we  can 
remember  the  last  sequence  number  used  on  the  previous 
connection.  It  is  not  necessary  to  choose  a clock-based 
ISN,  but  rather  just  continue.  (Cf.  (3)  section  4.3.1 
for  more  on  ISN  selection.)  After  notifying  the  Net 
Output  Process  to  send  a SYN,  control  Is  returned  to  the 
caller.  Uhen  the  connection  is  ready  for  use,  the  user 
process  is  noti fled. 

2)  SEND  LETTER  - This  call  causes  the  data 
contained  In  the  user  buffer  to  be  sent  on  the 
connection.  The  buffer  address  and  length  are  stored  in 
a common  data  area,  the  output  process  notified  of  work 
pending  and  control  returned  to  the  caller.  After  the 
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data  has  been  packet i zed  and  sent  (but  not 
Acknowledged),  the  ucer  process  is  notified.  Letter 
boundaries  are  ignored,  every  data  packet  has  the  End  Of 
Letter  (EOU  bit  set.  If  the  connection  is  not 
established,  the  data  is  queued  for  sending  later.  There 
can  be  at  most  one  outstanding  send.  The  mechanics  of 
sending  data  is  covered  in  section  xkx. 

3)  RECEIVE  LETTER  - The  user  process  is  notified 
when  data  arrives  on  the  connection  and  it  is  moved  into 
user- buffers  by  a RECEIVE.  RECEIVE  is  called  with  a 
buffer  pointer  and  maximum  byte  count  and  returns  the 
actual  byte  count.  Again,  letter  boundaries  are 
ignored.  After  delivery  to  the  user,  an  Acknowledgement 
is  sent  to  the  sender.  The  exact  details  of  moving  data 
into  the  user  buffer  is  covered  later  in  section,  xxx. 

4)  INTERRUPT  - A special  control  signal  Is  sent  to 
the  destination  Indicating  an  interrupt  condition.  All 
unsent  or  unacknowledged  data  will  be  flushed.  If  the 
connection  is  not  established,  an  error  is  returned. 

5)  CLOSE  CONNECTION  - This  command  causes  the 
connection  to  be  closed.  If  it  is  not  open,  an  error  is 
returned,  Pending  unsent  or  received  data  is  flushed, 
no  more  accepted  and  a FIN  sent  to  the  remote  TCP, 
Control  is  .returned  to  the  caller  and  the  user  is 
notified  when  the  close  is  finalized.  The  exact  process 
of  closing  a connection  is  covered  later  in  section  xxx. 


4 TCP  STRUCTURE 


4.1  OPERATING  ENVIRONHENT 

The  TCP  is  designed  to  operate  under  a very  simple  operating 
system  structure.  Each  proces‘3  has  a process  control  table  containing 
space  for  its  run-time  stack,  status  save  area  and  an  external  event 
scoreboard.  To  signal  a process  of  some  event,  the  signalling  process 
set's  a bit  in  the  called  process’  scoreboard.  Each  process  is 
responsible  for  periodically  polling  its  scoreboard  and  acting 
appropriately.  After  processing  the  signal,  the  process  then  clears  the 
flag  bit.  Each  process  runs  to  completion  and  context  switching  happens 
only  when  a process  explictly  releases  control.  The  only  operating 
system  primitive  is  one  that  causes  the  context  to  switch  to  the  next 
active  process.  All  processes  run  at  the  same  priority  level. 
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Using  a scoreboard  has  three  important  restrictions.  It  is  not 
possible  to  maintain  temporal  ordering  of  signals,  multiple  signals  of 
the  same  type  are  condensed  into  one,  and  it  is  not  possible  to  transfer 
any  data  along  with  the  signal,  The  first  two  restrictions  are  not 
critical  to  the  TCP  implementation;  indeed,  a TCP  Implementation  running 
under  a normal  message  queueing  operating  system  must  go  to  some  effort 
to  remove  extraneous  signals  resulting  from  process  asynchrony.  The 
third  restriction  requires  putting  data  associated  with  an  event  In  a 
"global"  I oca  I on  known  to  both  processes. 


There  must  also  be  I/O  devices  and  their  associated  device 
driver  routines.  It  is  assumed  that  the  devices  are  interrupt  driven, 
though  programmed  device  polling  is  possible  at  reduced  data  rates.  The 
following  devices  are  needed; 


1) 

Net 

input  device  - 

2) 

Net 

output  device  - 

3) 

Hardwai’e  timer  - 

4.2  NETWORK  INTERFACE 


To  allow  the  TCP  to  be  used  with  computer  networks  of  different 
structure  and  interfacing  requirements,  all  network  dependent  code  is 
concentrated  in  three  routines.  While  designed  for  the  ARPANET  and 
Packet  Radio  Network  this  partitioning  should  be  adequate  for  most  other 
network  configurations,  (The  most  obvious  exception  is  the  Very  Distant 
Hosts  in  the  ARPANET;  which  require  an  additional  watchdog  process  to 
provide  control  functions  for  the  IMP-HOST  line  protocol  used  (Cf.  [1] 
appendix  F) . ) The  routines  and  their  functions  are; 

INITIALIZENETUORK  - Called  on  system  initialization,  this  routine 
initializes  the  device  driver  routines  and  performs  the 
HOST-NETUORK  start-up  sequence.  It  returns  when  the  network 
is  ready  to  deliver/accept  messages  to/from  the  host 
computer. 


NETINPUT  - Passed  the  address  of  a packet  buffer,  this  routine 
initiates  action  to  accept  a message  from  the  network.  It 
performs  the  network-dependent  processing  of  the  NETWORK- 
HOST  message  header,  e.g.  In  the  ARPANET,  it  would  verify 
that  the  message  is  of  type  0 (regular  packet)  and  not  a 
special  IMP-HOST  message.  Control  returns  to  the  caller 
when  a valid  message  is  received. 


NETOUTPUT  -.  Called  with  the  address  of  a message  to  send,  this 
routine  performs  the  network-dependent  formatting  of  the 
HOST-NETWORK  message  header.  Transmission  of  the  message 
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into  the  network  is 
caller  when  the  output 


started  and  control 
is  completed. 


returned 


to  the 


4.3  PROCESS  INTERACTION 


The  TCP  is  composed  of  t»o  processes, 
me  mr  13  i„Kio  rniitines  sharing  a common  data  case,  ine 

and  a set  of  cggh  process  in  non-interruptable,  running 
Transmission  Control  “ „-,a  sional  fiags.  The  TCP  INPUT  process 
to  completion,  and  J ^er  ®.o?i  f U user  process  of  neu 
handles  incoming  OUTPUT  process  to  send  error  packet  or 
data  received  or  919"®'®  process  is  the  only  process  that 
various  control  packets.  Th-  ..  P ...P_  output  process  Is  the  only 
receives  data  from  the  lOP  OUTPUT  process,  on  command, 
sender  of  data  to  the  ne  uo  k The^TUr^^.u^ 

sends  error  packets  or  controp  1^  gigp  ij  responsible  for 
data  on  request  of  the  u.e  P . ^Ig3,ly.  The  Network  device 
•retransmitting  n°*if^  o<  "'‘p"®-” 
driver  also  the  computer  periodical  ly  and  Its  device 




4.4  CONNECTION  CONTROL  VARIABLES 


a Transmission  Control  Block  uudj. 

TCB  and  their  length. 

DHOST  - (16  b'ts)  The  local  PSN  ®^dress  of  the 

th^  siiras'  he  TCP  address  If  In  the  local 
fetwtrL  Oth^rwtse.  the  destination  NET  id  is  used  to 
determine  the  local  gateway  address. 


DNET  - (8 
4-9 


bits)  The  destination  network  Id. 
1 for  list  of  assigned  network  ids.) 


Id.  (Cf.  13)  section 


OTCP  - 116  bits)  The  destination  TCP  id 


DPORT  - (2A  bits)  The 

OTCP,  they  form 


destination  PORT  id. 
the  destination  socket. 


Along  ui th 


DNET  and 


SNET  - (8  bits)  The  network  id  of  the  local  network. 

STCP  - (16  bits)  The  TCP  id  of  the  local  TCP. 

SPORT  - (2A  bits)  The  local  PORT  id.  Along  with  SNET  and  STCP,  they 
form  the  local  socket  number. 
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CONNECT  I ONSTATb'  - (8  bits)  The  acMons  performed  by  the  TCP  depend 
upon  what  has  happened  previously.  There  are  six 
"connection  states"  in  a user  TCP.  They  are: 

1)  CLOSED  - The  connection,  as  such,  does  not 
exist. 

2)  SYNSENT  - The  user  process  has  done  an  OPEN  and 
a SYN  has  been  sent  to  the  foreign  TCP  in  an  attempt  to 
establish  a connection.  He  wait  for  the  ACKnowledgement 
of  our  SYN  before  going  to  the  ESTABLISHED  state  and 
notifying  the  user  process  that  the  connection  is 
usable. 

3)  SniULINIT  - After  sending  a SYN  to  establish  a 
connection,  we  received  a SYN  without  an  ACKnowledgement 
of  our  SYN  from  the  foreign  TCP.  This  represents  an 

.attempt  by  both  ends  to  open  the  connection 

simultaneously.  Ue  send  an  ACKnowledgement  of  the  SYN 
we  received  and  initialize  the  connection  dependent 
variables.  We  wait  for  the  ACKnowledgement  of  our  SYN 
before  going  to  the  ESTABLISHED  state  and  notifying  the 
user  process  that  the  connection  is  usable. 

A)  ESTABLISHED  - The  three-way  handshake  to 

synchronize  the  connection  was  successful  and  the 
connection  is  usable  for  data  transfers. 

5)  FINUAIT  - The  user  process  has  done  a CLOSE  and 
we  have  sent  out  the  FIN.  Ue  wait  for  the  FIN  to 
timeout  or  to  receive  a FIN  and  ACKnowledgement  of  our 
FIN  before  going  to  the  CLOSED  state. 

G)  FINRECEIVED  - Ue  have  received  a FIN  from  the 
foreign  TCP.  The  user  is  notified  of  the  remote  close 
and  we  send  a FIN  and  ACKnowledge  the  receive  FIN.  Ue 
now  wait  for  an  ACKnowledgement  of  our  FIN  or  its 
timeout  before  going  to  the  CLOSED  state. 

RCVSEQ  - (32  bits)  The  next  sequence  number  expect»3d 

RCVUS  - (IG  bits)  The  receive  window  size. 

INITSEQ  - (32  bits)  The  initial  receive  sequence  number  used  by  the 
foreign  TCP,  "^his  Is  used  to  detect  old  duplicates  of  the 
SYN  that  estaulished  the  connection. 

SNDSEQ  - (32  bits)  The  next  sequence  number  to  send. 

SNOWS  - flG  bits)  The  send  window  size. 
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LASTUGEQ  - (32  bits)  The  last  sequence  number  used  to  uodata  aanri 
window.  ooiiu 

LSUEDGE  - (32  bits)  The  left  send  window  edge  sequence  number, 

INPUTHEAD  - (16  bits)  The  pointer  to  the  head  of  the  receive  data 
reasser.bly  ring  buffer. 

BUFFERPOI^rtR  - (16  bits)  The  address  of  the  start  of  the  user’s 
send  buffer. 

BUFBYTEC'JUNT  - (IG  bits)  The  number  of  bytes  in  the  user’s  send 
butter.  The  byte  count  and  buffer  pointer  are  set  ■ when  the 

user  does  a send  and  are  updated  as  the  output  process 
-emoves  and  sends  data.  ^ process 

RTXUAKCUP  - (18  bits)  Count  of  the  number  of  retransmissions  sent 
Mthout  receiving  any  neu  ACKs.  It  is  cleared  uhen  a valid 
comes  in.  When  the  number  of  retransmissions  exceeds  a 
preset  value,  the  user  is  notified  of  "TCP  not  responding." 

RTXPOiNTER  • (IG  bits)  The  pointer  to  the  head  of  the 

retranSiH sslon  ring  buffer. 

RTXCOUNT  - (IG  bits)  The  number  of  bytes  of  data  In  the 

retransmi  ss’ion  ouff&r.- 

RTXCONTROL  - (IG  bits’  It  contains  the  control  field  of  the  control 
packet  queued  up  to  be  retransmitted.  If  zero,  then  no 
control  packet  queued  up.  Only  one  control  packet  can  be 
queued  for  retransmission. 

RTXCNTRLSEQ  - (32  bits)  The  send  sequence  number  of  the  control 

packet  queued  up  to  be  retransmitted. 

RTXDATASEQ  - (32  bits)  The  send  sequence  number  of  the  data  byte  at 
the  head  of  the  retransmission  ring  buffer.  ^ 

In  addition,  there  are  several  -issembly-t ime  constants  that  set 
the  size  of  various  buffers. 

MAXPACKETSIZE  - The  maximum  number  of  data  bytes  that  can  be  put  in 
the  text  field  of  a internet  packet.  MAXPACKETSI ZF 
internetwork  header  length  and  length  of  local  PSN  control 
fields  determine  the  size  of  the  send  packet  buffer. 

MAXRCYWS  - The  maximum  receive  window  size  is  set  by  the  size  nf 
the  reassembly  ring  buffer. 

MAXRTXCOUNT  - The  maximum  amount  of  data  queued  ud  to  hn 
retransmitted.  This  determines  the  size  of  the 

retransmission  ring  buffer. 
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There  are  also  several  buffers  associated  with  the  connection. 
They  are: 

RCVPKTBUFFER  - The  buffer  that  incoming  packets  are  written  into  by 
the  network  device  driver. 

REASSflBUFFER  - The  ring  buffer  where  Input  data  is  reassembled  ami 
stored’ pending  deliver  to  the  user  process, 

REASSflFLAGS  - A boolean  vector  that  indicates  which  elements  of  the 
reassembly  buffer  contain  a data  octet. 

SENDPKTBUFFER  - The  buffer  that  outgoing  packets  are  constructed  In 
and  sent  out  by  the  network  device  driver. 

RTXBUFFER  - The  buffer  where  data  waiting  to  be  Acknowledged  is 
enqueued. 


4.5  INPUT  PACKET  HANDLER 

After  initializing  the  local  network  interface,  the  TCP  INPUT 
process  is  awakened  when  a packet  arrives  from  the  network.  The  packet 
is  checked  for  an  internetwork  message;  malformed  packets  are  simply 
discarded.  The  validity  check  involves  verifying  that  the  message  Is 
long  enough  to  contain  the  TCP  packet  header  and  *he  packet  header 
version  number  is  correct.  The  BOS  and  EOS  control  bits  must  both  be 
asserted;  the  current  implementation  can  not  handle  fragmented  segments. 
The  checksum  is  finally  calculated  and  detectably  damaged  packets  are 
discarded;  they  will  be  re-transmi tted  by  the  sender. 

After  validation,  the  message  is  checked  for  special  function  or 
error  Information  and  processed  appropriately.  In  this  preliminary 
specification,  their  handling  is  not  detailed;  but  the  TCP  must  be 
sensitive  to  RESET  ALL,  RESET  and  QUERY  special  functions  and  all  error 
condi t ions. 

Packets  without  control  dispatch  refer  to  specific  connections; 
the  foreign  and  local  sockets  are  checked  against  those  of  the  single 
connection  we  service,  if  different,  an  error  message  (connection  non-- 
existent) is  constructed  and  queued  to  be  sent  by  the  Net  Output 
Process. 


If  in  the  SYNSENT  state  and  we  receive  a SYN  with  INT,  DSN  or 
FIN  then  the  SYN  is  malformed  and  an  error  is  returned.  If  the  packet 
acknowledges  the  SYN  we  sent,  the  connection  is  synchronized.  He 
Acknowledge  the  received  SYN,  Initialize  the  Transmission  Control  Block 
and  notify  the  user  of  connection  establishment.  If  instead  of  an  ACK, 
the  packet  contains  only  a SYN,  then  we  have  a simultaneous  attempt  by 
both  sides  to  open  the  connection.  (Cf.  [3]  section  4.3.2  for  details 
of  SYN  collision.)  The  new  connection  state  Is  SIflULINIT. 
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In  the  SII1ULINIT  state,  if  we  receive  a SYN  it  is  first  checked 
to  see  if  it  is  a duplicate  of  the  SYN  that  caused  the  state  change  to 
SIHULINIT.  If  so,  then  just  ACknowledcje  receipt.  Otherwise  we  have  two 
different  SYNs  and  can  not  tell  which  is  valid,  so  we  send  back  an  errcr 
and  reinitialize.  If  instead  of  a SYN,  we  get  an  Acknowledge  of  our 
SYN,  the  connection  has  been  established  by  a four-way  handshake. 
Notify  the  user  and  process  any  data  that  may  accompany  the  ACk. 

Once  the  connection  is  established,  errors  are  sent  for  ail  SYNs 
received,  except  for  duplicates  of  the  original. 
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5 USER  INTERFACE  LOGIC  OOCUhENTATlON 


OPEN  (OPENBLOCKPOINTER): 

if  CONNECTIONSTATE  notequal  CLOSED  then 
return  (connection  already  open  error) 


(:rove  socket  addresses  into  control  block) 

address) 

initconnectFon 


comment-  return  to  (aller. 

becornsH  established  or 
return  (ok) 


notify  user  process  when  connection 
on  error  condi t ion. 


SEND  ii'IFFERADDRESS,  BUFFERLENGTH) : 

JOTiment-  put  buffer  pointer  and  length  into  TCB  for  send  process 


if  BUFBYTECOUNT  notequal  0 then 
return  (too  many  SENDs  error) 

e I se 

begin 

PUFFERPOl NTER; ^BUFFCrAODREGS 

BUFBVTECOUNT; -BUFFERLENGTH 

(notify  TCP  OUTPUT  PROCESS  to  send  data) 

end 

return  (ok) 


INTERRUP" 

if  CONNECTIONSTATE  r-  ‘equal  ESTABLISHE'.  then 
return  (connection  not  open  error) 

(notify  TCP  OUTPUT  PROOESS  to  flush  send  data) 
(notify  TCP  OUTPUT  PROCESS  to  send  INT) 
return  (ok) 


RECEIVE  (BUFFERADDRESS,  BUFFERLENGTH.  result  BYTECOUNTIi 
it  CONNECTIONSTATE  notequal  ESTABLISHED  then 
return  (connection  not  opened  error) 

PTRi. BUFFERADDRESS 
BYTECOUNTi-0 

‘^f’ile^^BYTECOUNT  < BUFFERLENGTH)  and  REASSNFLAGStlNPUTHEAD)  do 
user  buffer  (PTR)  i-  REASSHBUFFER  (INPUTHEAD) 
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REASSfIFLAGS  (INPUTHEAO)  :-FAiSE 
PTR:nPTR+l 

INPUTHEAD  ;»  (INPUTHEAD+1)  MOD  flAXRCVUS 

BYTECGUNT: -BYTECOUNT+1 

end 

RCVSEQ  : « RCVSEQ  + BYTECOUNT 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

if  REASSMFLAGS  (INPUTHEAD)  then 

(notify  user  process  of  data  remaining  to  be  received) 

return  (ok) 


CLOSE: 

case  CONNECTIONSTATE  of 
-SYNSENT: 
DELETECONNECTION 


.SIMULINIT: 

-ESTABLISHED: 

begin 

CONNECriONSTATE:-FINUAIT 
(notify  TCP  OUTPUT  PROCESS 
(notify  TCP  OUTPUT  PROCESS 
end 


to  flush  send  data) 
to  send  FIN) 


-CLOSED: 

-FINUAIT: 

-FINRECEIVED; 


return  (ok) 
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B TCP  INPUT  PROCESS  LOGIC  OOCUNENTATION 
TCP  INPUT  PROCESS; 

(wait  for  network  interface  initialization) 

LOOP;  NETINPUT  (RCVPkTBUFFER) 

if  (packet  length  greaterthan  or  equal  minimum  permitted)  and 
(packet  header  version  number  equal  0)  then 
beg  in 

comment-  packet  verified  as  a TCP  message, 
if  (packet  BOS  bit  *1  and  packet  EOS  bit  -1)  then 
beg  i n 

comment-  unfragmented  message,  process. 

If  CHECKSUM  (RCYPKTBUFFER)  - 0 then 

comment-  checksum  ok,  packet  not  damaged, 
if  (packet  Control  Dispatch  bits  equal  0)  then 
HANDLEREGULARPACKET 

^ ^^HANDLESPECIALPACKET 

end 

e I se 

comment-  fragmented  message,  code  to  do  fragment 
reassembly  goes  in  here,  but  for  now  just... 

( log  error) 

end 

e I se 

comment-  garbage  packet 
(log  error) 

goto  LOOP 


CHECKSUM  (PACKETPOINTER); 

comment-  computes  the  IG  bit  I’s  com,  ?ment  sum  of  the  header 
and  text  fields  of  the  packet,  i.  the  sum  is  0,  then  the 
packet  is  not  (hopefully!)  damaged. 


HANDLEREGULARPACKET; 

if  ADDRESSCHECK  then 
beg  i n 

comment-  packet  is  for  this  correction,  process  according  to 
connection  state. 

case  CONNECT  I ONSTATE  of 
-SYNSENT; 

if  (packet  SYN  bit  -1)  then 
begin 

if  (packet  FIN,  INT  or  DSN  bits  -1)  then 


12 


TCP0  implementation 


January  2B,  1976 


comment-  should  not  have  these  control  bits  set, 
return  unacceptable  SYN  error. 

Xril  TERROR  (EFP+USYN) 

e I se 

if  (packet  ACK  bit  -1)  then 
beg  i n 

if  ACCEPTABLEACK  then 
begin 
SETTCB 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

CONNECT  I ONSTATE ; =ESTABL I SHED 

(notify  user  of  connection  established) 

HANDLEACK 

end 

e I se 

Xm TERROR  (EFP+USYN) 
end 

e i se 

CUliHM«nl-  I iiiu  I tai'icOuS  atlerrtplo  to  OpBM  tlio 
connection, 
beg  i n 

CONNECTIONSTATEt-SinULINIT 

SETTCB 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 
end 

end 

-SmULINIT: 

if  (packet  SYN  bit  -I)  then 
beg  i n 

if  (packet  seq  number  equal  INITSEQ)  then 

comment-  duplicate  of  first  SYN,  don’t  send  an 
error,  but  force  an  Acknowledgement. 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

e I se 

begin 

comment-  we  have  received  two  different  SYNs  and 
can’t  tell  which  to  believe,  so  send  error 
message  and  reinitialize  connection  and  try 
again. 

Xfll  TERROR  (EFP+USYN) 

INITCONNECTION 

end 

end 

else 

if  (packet  ACK  bit  ■!)  then 

if  ACCEPTABLEACK  and  INRCVUINDOU  then 
beg  i n 

comment-  acknowledged  our  SYN,  so  connection 
now  synchronized. 

CONNECT  I ONSTATE : «ESTABL I SHED 

(notify  user  of  connection  established) 
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NORMALCASE 

end 

-ESTABLISHED: 

if  (packet  SYN  bit  -1)  then 
beg  i n 

if  (packet  seq  number  equal  INITSEQ)  then 
begin 

comment-  duplicate  of  the  original  SYN  that 
established  connection,  force  an  ACK  and 
process  any  data. 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

If  INRCVUiNOOU  then 
NORMALCASE 
end 

e I se 

comment-  unacceptable  SYN. 

XMl TERROR  (EFP+USYN) 
c:->d 

e I se 

oegin 

if  INRCVUINOOU  then 
NORMALCASE 

else 

(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

end 

. INUAIT; 

.f  INRCVUINOOU  and  (packet  FIN  bit  =1)  then 
begin 

comment-  ue  have  sent  a FIN  and  now  have  received  a 
FIN.  ACKnowledge  FIN  and  see  if  can  delete  the 
connection. 

RCVSEQ:*=  (packet  seq  number)  + (packet  tent  length) 
RCVSEQ:=RCVSEQ  + CONTROLLENGTH  (RCVPKTBUFFER) 
CONNECT  I ONST ATE : -F 1 NRECE 1 VED 
(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 
if  (packet  ACK  bit  - 1)  and  ACCEPTABLEACK  then 
HANDLEACK 
end 

-FI NRECE 1 VED: 

If  INRCVUINOOU  and  (packet  ACK  bit  -1)  then 
if  ACCEPTABLEACK  then 
HANDLEACK 


end 

else 

XMI TERROR  (EFP+NONX) 


return 
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INRCVUINDOU: 

comment-  determines  if  any  part  of  the  packet  that  just  came  In 
lies  inside  the  receive  window. 


ACCEPTABLEACK: 

comment-  return  TRUE  if  packet  ACKs  something  we  sent  that  has 
rot  yet  been  ACKed,  i.e.  LSUEDGE  <»  ACKfield  <■  SNOSEQ 


NORflALCASE: 

comment-  this  processes  the  normal  case  of  putting  new  data  into 
the  right  place  in  the  circular  reassembly  buffer,  also 
processes  other  possible  things  in  packet. 

if  (packet  ACK  bit  -1)  and  ACCEPTABLEACK  then 
HANDLEACK 

if  (packet  INI  bit  - 1)  then 
HANDLE  I NT 

if  (packet  text  length  greater  than  0)  then 
HANDLEDATA 

if  (packet  DSN  bit  » 1)  then 
HANDLEDSN 

if  (packet  FIN  bit  - 1)  then 
HANDLER  IN 

return 


HANDLEACK; 

comment-  correlates  the  ACK  that  came  in  (and  window,  etc.)  with 
what  we  have  already  put  in  the  control  block,  it  le  where 
confirming  ACKs  will  remove  data  from  the  Retranemi esion 
ring  buffer. 

if  PRECEDE  (LASTU5EQ,  (packet  sequence  number)  ) then’ 
begin 

comment-  update  the  send  window  size  If  this  is  the  latest 
packet  we  have  seen. 

SNDUS  (packet  window  size  field) 

LASTUSEQ  (packet  sequence  number) 
end 

comment-  convert  next  sequence  number  expected  to  sequence 
number  of  last  octet  Acknowledged, 

ThPRFn:-(packet  ACK  field)  - 1 
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LSUEDGE  (packet  ADC  field) 

if  RTXCONTROL  notequal  0 then 
comment-  see  if  control  ADCed. 

if  PRECEOE  (RTXCNTRLSEQ,  TfIPSEQ)  then 
begin 

• comment-  if  our  FIN  was  ACKed,  delete  the  connection, 
if  RTXCONTROL  = FIN  packet  then 
• DELETECONNECTION 
RTXCONTROL: -0 
end 

if  RTXCOUNT  notequal  0 then 

comment-  see  if  any  data  is  ACKed  and  if  so,  remove  them 

if  PRECEDE  (RTXUATASEQ,  ThPSEQ)  then 
begin 

COUNT: -TMPSEQ  - RTXDATASEQ  + 1 
RTXCOUNT;. RTXCOUNT  - COUNT 

RTXPOINTER;-  (RTXPOINTER  + COUNT)  (10D  MAXRTXCOUNT 

RTXDATASEQ: -RTXDATASEQ  + COUNT 

end 

return 


SETTCB: 

comment-  fills  received  information  into  control  block  from 
arriving  SYN  packet 

RCVSEQ  is  the  next  sequence  number  expected, 

SNDUS  is  the  send  window  size, 

INITSEQ  is  the  initial  receive  sequence  number  used, 
LASTUSEQ  is  the  last  sequence  number  used  to  update  send 
window, 

LS14EDGE  is  the  left  send  window  edge. 

SNDUS;-  (packet  window  size) 

INITSEQ;-  (packet  seq  number) 

LASTUSEQ;-  (packet  seq  number) 

RCVSEQ;-  (packet  eeq  number)  + 1 

return 


HANDLEDATA: 

comment-  this  routine  moves  data  from  the  input  packet  into  the 
circular  reassembly  buffer. 
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INPUTHEAD  is  a pointer  to  the  head  of  the  reassembly  buffer, 
RCVSEQ  is  the  left  receive  window  edge  sequence  number, 
PINDEX  is  the  index  into  the  text  field  of  the  input  packet 
REA5SMBUFFER  is  the  actual  reassembly  buffer  and 
REASSfIFLAGS  is  a vector  of  flags  indicating  which  bytes  in 
the  REASSMBUFFER  contain  valid  user  data. 

MAXRCVUS  is  the  length  of  the  reassembit;  buffer 

PINDEX: -0 

START:-  (packet  seq  number) 

if  PRECEDE  (START.  RCVSEQ)  then 
beg  i n 

PINDEX: -RCVSEO-START 

START: -RCVSEQ 

end 

PTR:-  (START  - RCVSEQ  + INPUTHEAD)  flDD  MAXRCVUS 

AMOUNT;-  MIN  (RCVUS,  (packet  text  length)  ) 

for  I:-  PINDEX  until  AMOUNT  + PINDEX  - 1 do 
beg  i n 

REASSMFLAGS  (PTR):-TRUE 

REASSMBUFFER  (PTR):=  (packet  text  field  indexed  by  I) 

PIR:-  (PTR+1)  MOD  MAXRCVUS 
end 

■ i f START  - RCVSEQ  then 

(notify  USER  of  new  data  received  at  left  window  edge) 
return 


HANDLE  I NT; 

RCVSEQ;-  (packet  seq  number)  + 1 
(notify  TCP  DUTPUT  PROCESS  to  send  ACK) 
(flush  receive  data) 

(notify  USER  of  INTERRUPT  request) 

return 


HANDLEFIN: 

comment-  handle  a valid  FIN  arriving  when  connection  ESTABLISHED 

CONNECT  1 ONST ATE ; -F I NRECE I VEO 

(notify  TCP  OUTPUT  PROCESS  to  flush  send  data) 
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(notify  USER  of  remote  close) 

RCVSEQ:-  (packet  seq  number)  + (packet  text  length) 
RCVSEQt-RCVSEQ  + CONTROLLENGTH  (RCVPKTBUFFER) 
(notify  TCP  OUTPUT  PROCESS  to  send  ACK) 

(notify  TCP  OUTPUT  PROCESS  to  send  FIN) 

return 


HANDLEDSN: 

comment-  method  for  handling  DSN  is  yet  unresolved 
return 


ADDRESSCHECK: 

comment-  returns  TRUE  if  the  packst  is  for  the  one  valid 
connection,  the  foreign  NET,  TCP  & PORT  address  and  the 
local  PORT  addresses  must  agree  with  those  of  the  open 
connection. 

if  CONNECT lONSTATE  - CLOSED  then 
return  FALSE 

If  (packet  source  NET  field)  notequal  DNET  then 
return  FALSE 

if  (packet  source  TCP  field)  notequal  DTCP  then 
return  FALSE 

if  (packet  source  PORT  field)  notequal  DPORT  then 
return  FALSE 

If  (packet  destination  NET  field)  notequal  SNET  then 
return  FALSE 

if  (packet  destination  TCP  field)  notequal  STCP  then 
return  FALSE 

• if  (packet  dest inat ion  PORT  field)  notequal  SPORT  then 
return  FALSE 

e I se 

return  TRUE 


HANDLESPECIALPACkETi 

comment-  handle  special  functions  or  error  message  packets 


18 


TCP0  implementation 


January  25,  1976 


case  (packet  control  dispatch  field)  of 
-SPECIALFUNCTION: 
begin 

case  (packet  control  data  octet)  of 
-RESETALL: 

if  (packet  source  TCP  field)  - DTCP  then 
RESETCONNECTION 

-RESET: 

i f ADDRESSCHECk  and  ACCEPTABLEACK  then 
RESETCONNECTION 

-QUERY: 

if  ADDRESSCHECk  then 
(send  status  message) 

end 

-ERROR: 

if  ADDRESSCHECk  then 
beg  i n 

comment-  process  error  directed  at  uc. 

case  (packet  control  data  octet)  of 
-USYN: 

if  CONNECT  I ONSTATE  - SYNSENT  then 
(send  a reset) 

^ ^^if  CONNECT  I ONSTATE  - SIHULINIT  then 
INITCONNECTION 

-NONX; 

-INACC; 

begin 

case  CONNECT  I ONSTATE  of 
-SinULINIT: 

INITCONNECTION 

-ESTABLISHEO: 
if  INRCVUINDOU  then 

(notify  user  process  of  error) 

-FINUAIT: 

If  INRCVUINDOU  then 
DELETECONNECTION 

end 

end 

return 
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INITCONNECTIONj 

comment-  initialize  connection  state 
CONNECT  I ONSTATE; -SYNSENT 

(notify  TCP  (!)UTPUT  PROCESS  to  flush  send  data) 

(flush  receive  data) 

comment-  pick  initial  sequence  number  by  adding  a constant  to 
last  sequence  number  used  on  previous  connection, 
SNDSEQj-SNDSEQ  + 1 

(notify  TCP  OUTPUT  PROCESS  to  send  SYN) 
return 


CONTROLLENGTH  (packet  buffer): 

comment-  returns  the  number  of  octets  used  in  the  packet  by 
control  functions. 

COUNT; -0 

i f (packet  SYN  bit  -1 ) 

then 

COUNT; -1 

if  (packet  INT  bit  -li 
COUNT; -COUNT  +1 

then 

i f (packet  FIN  bit  -1) 
COUNT; -COUNT  +1 

then 

if  (packet  DSN  bit  -1) 
COUNT; -COUNT  +1 
return  COUNT 

PRECEDE  (PARMl,  PARM2); 

then 

comment-  returns  true  if  PARI12  - 2**1B  < PARMl.  PARMl  and  PARM2 
both  being  32  bit  numbers,  this  is  just  a special  inwindow 
test  that  returns  true  if  PARfll  precedes  or  equals  PARI12 
in  the  circular  sequence  number  space. 


Xn I TERROR  (ERROR  CODE); 

comment-  send  an  error  message  to  the  remnte  TCP.  the  error  code 
is  passed  as  a parameter,  see  (3)  pi^ction  2.4.3  about 
possible  error  codes. 

(swap  source  & destination  socket  ids) 

(put  input  packet  sequence  number  in  ACK  field) 

(set  Control  Dispatch  to  indicate  error  present) 

(put  ERROR’ CODE  in  control  octet) 

(notify  TCP  OUTPUT  PROCESS  to  send  error  packet) 

(wait  for  completion  of  error  send) 

(set  error  send  complete  flag  to  false) 
return 
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DELETECONNECTION: 

comment-  set  the  connection  state  to  CLOSED,  notify  the  user  of 
close  completion  and  flush  all  the  queues  and  stuff, 

CONNECTIONSTATE:-CLOSEQ 

(notify  user  process  of  CLOSE  completion) 

(notify  TCP  OUTPUT  PROCESS  to  flush  send  data) 
return 
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7 TCP  OUTPUT  PROCESS  LOGIC  DOCUrENTATION 

TCP  OUTPUT  PROCESS; 

comment-  initialize  Net  interface. 

INITIALIZENETUORK 

(notify  TCP  INPUT  PROCESS  of  initialization  complete) 

LOOP:  (uait  for  uork  to  process) 

i f (need  to  send  error)  then 
beg  i n 

(move  packet  from  RCVPkTBUFFER  into  SENDPKTBUFFER) 

SENDPACkET 

(notify  TCP  INPUT  PROCESS  that  errof'  has  been  sent) 

(set  need  to  send  error  flag  to  false) 
end 

if  (need  to  flush  send  data)  then 
beg  iri 

comment-  flush  the  send  data  and  retransmission  queues, 
first  remove  any  outstanding  SENDs. 

if  (need  to  send  data)  then 
begin 

(set  need  to  send  data  flag  to  false) 

(notify  USER  of  eend  completion,  ready  for  new  send) 
end 

BUFBYTECOUNT;-0 

comment-  then  remove  any  data  or  control  to  be  retransmitted 

RTXCOUNT;»0 

RTXCONTROL;»0 

RTXUAKEUP:-0 

(set  need  to  retransmit  data  flag  to  false) 

(set  need  to  retransmit  control  flag  to  false) 

(set  need  to  flush  send  data  flag  to  false) 

end 

if  (need  to  send  SYN,  INT  or  FIN)  then 
beg  i n 

comment-  construct  a packet  and  add  the  appropriate  control 

bits. 

INITIALIZEPACkET 
if  (need  to  send  SYN)  then 
(set  packet  SYN  bit  =1) 
if  (need  to  send  INT)  then 
(set  packet  INT  bit  »1) 
if  (need  to  send  FIN)  then 
(set  packet  FIN  bit  -1 ) 

(set  need  to  send  SYN,  INT  and  FIN  flags  to  false) 
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SENDPACK5T 

RTKCNTRI.SEQ:-SNDSEQ 

RTXCONTROL:-  (packet  control  word  field) 

SNDSEQi-SNDSEQ  + CONTPOLLENGTH  (SENDPKTBUFFER) 
end 

If  (need  to  send  data)  then 
begin 

comment-  SPACELEFT  is  amount  of  space  left  In  send  window 
■f^tXCOUNT  is  the  number  of  bytes  In  the  retransmission 
queue, 

MAXRTXCOUNT  is  the  length  of  the  retransmission  queue 
buffer, 

RTXSPACE  is  amount  of  space  left  in  retransmission  queue 
DAXPKTSIZE  is  maximum  number  o^  data  bytes  in  packet 
BUFBYTECOUNT  is  number  of  bytes  in  user  send  buffer 
. BUFFERPOINTER  is  address  of  start  of  user  send  buffer. 

SPACELEFT; -f NOUS  - SNDSEQ  + LSUEDGE 
RTXSPACE; -riA/.RTXCOUNT  - RTXCOUNT 

COUNT;-  niN  (S:^ACELEFT.  BUFBYTECOUNT,  RTXSPACE,  MAXPKTSIZE) 

If  COUNT  notequal  0 then 
beg  I n 

INITIALIZEPACkET 
if  RTXCOUNT  - 0 then 
RTXDATASEQ: -SNDSEQ 

PKTPTR;-  (index  cf  start  of  packet  text  area) 
for  I;-l  until  COUNT  do 
beg  i n 

(copy  byte  from  user  buffer  into  packet) 

• (copy  byte  from  buffer  into  retransmission  queue) 
BUFFERPOINTER; -BUFFERPOINTER+1 
RTXPOINTER;-  (RTXPOINTER  + 1)  NOD  HAXRTXCOUNT 
PkTPTR;-PKTPTR+l 
BUFBYTECOUNT; -BUFBYTECOUNT-1 
RTXCOUNT ;.RTXC0UNT+1 
end 

(set  packet  text  length  equal  COUNT) 

SENDPACk'ET 

SNDSEQ; -SNDSEH  + COUNT 
If  BUFBYTECOUNT  - 0 then 
begin 

. (set  need  to  send  data  flag  to  false) 

(notify  USER  of  send  completion,  ready  for  next  send) 
end 
end 

If  (need  to  retransmit  data)  and  CONNECT  I ONSTATE  - ESTABLISHED 
then 
begin 

comment-  RTXUAKEUP  counts  the  number  of  retransmissions 
sent  without  receiving  any  ACKs  back.  It  Is  cleared 
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in  HANDLEACK  when  a valid  one  conies  in  and  incremented 
by  the  clock  interrupt  routine  before  notifying  the  SEND 
process  to  retiansmit  data  or  control.  if  the  data 
remains  on  the  retransmi ssi on  queue  too  long,  the  user 
is  notified. 

if  RTXUAKEUP  greaterthan  iiiaximum  allowed  then 

comment-  the  foreign  TCP  has  failed  to  ACK  data  that  has 
been  waiting,  it  is  assumed  that  the  destination 
i s not  respondi ng 

(notify  USER  that  destination  TCP  not  responding) 

else 

begin 

comment-  now  retransmit  the  data  queued  up. 

SPACELEFT;»SNDUS  - RTXDATASEQ  + LS14EDGE 
COUNT:*  niN  (SPACELEFT,  RTXCOUNT,  MAXPICTSIZE) 
if  COUNT  notequal  0 then 
begi  n 

INlTlALiZEPACkET 

RTXPTR;-RTXP01NTER 

PKTPTR: «( index  of  start  of  packet  text  area) 
for  I;*l  until  COUNT  do 
begi  n 

SENDPKTBUFFER (PKTPTR) ; -RTXBUFFER (RTXPTR) 
PKTPTR;=PKTPTR+1 

RTXPTR;*  (RTXPTR+l)  MOO  flAXRTXCOUNT 
end 

(packet  sequence  number) :■  RTXDATASEQ 
(packet  text  length);-  COUNT 
SENDPACKET 
end 

end 

(set  need  to  retransmit  data  flag  to  false) 
end 

if  (need  to  retransmit  control)  then 
beg  i n 

if  RTXCONTROL  notequal  0 then 
beg  i n 

if  RiXUAkEUP  greaterthan  maximum  allowed  then 
begin 

(notify  USER  that  destination  TCP  not  responding) 
if  RTXCONTROL  equals  FIN  f. acket  then 

comment-  a FIN  packet  has  timed-out.  so  close 
the  connection  anyway. 

OELETECONNECTION 

end 

e I se 

begi  n 

SPACELEFT; -SNDUS  - RTXCNTRLSEQ  + LSUEDGE 
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if  SPACELEFT  greater  than  0 then 
beg  i n 

INITIALIZEPACKET 

(packet  sequence  number) ;=  RTXCNTRLSEQ 
(packet  control  worcl):«=  RTXCONTROL 
SENDPACKET 
end 

end 

end 

(set  need  to  retransmit  control  flag  to  false) 
end 

i f (need  to  send  ACK)  then 
beg  i n 

INITIALIZEPACKET 

SENDPACKET 

end 

goto  LOOP 


INITIALIZEPACKET: 

comment'  initialize  the  internet  header 

(move  SNOSEQ  into  packet  seq  field) 

(move  fore:v,n  socket  id  Into  packet) 

(move  local  socket  id  into  packet) 

(move  RCVUS  ’nto  packet) 

(zei  0 ^ut  rest  of  packet  header) 
i f (n:ied  to  send  ACK)  then 
begin 

comment-  piggyback  ACK  onto  data  or  control  packet 
(set  packet  ACK  bit  »*1) 

(put  receive  left  uiindou  edge  in  ACK  field) 

(set  need  to  send  ACK  flag  to  fals^) 
end 

return 


SENDPACKET: 

comment-  calculate  a checksum  and  put  it  in  the  header  and  then 
sent  it. 

(put  zero  in  packet  checksum  ilold) 

(packet  checksum  f i e I d) : -CHECKSUH  (3ENDPKTBUFFER) 

NETDUTPUT  (SENDPKTBUFFER) 
return 
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8 ARPANET  INTERFACE  LOGIC  DOCUMENTATION 
INITIALIZENETUORK: 

comment-  initialize  the  device  drivers  and  send  NOPs  to  IMP 

(reset  network  device  driver) 

(construct  IMP  NOP  message) 

for  I:»l  until  A do 
begin 

comment-  send  four  NOPs  to  the  IMP 

(give  NOP  message  to  network  driver  to  send) 

(wait  until  message  sent) 
end 

return 


NET  INPUT  (PACKETBUFFER)J 

comment-  start  input  from  IMP 

LOOP;  (start  message  input  from  IMP) 

(wai t until  f ini  shed) 

if  (message  not  on  experimental  links,  155-158)  then 
goto  LOOP 

if  (message  type  notequal  regular  or  minimum  effort)  then 
goto  LOOP 

comment-  return  message  to  TCP 
return 

NETOUTPUT  (PACKETBUFFER); 

(initialize  IMP-HOST  header) 

(give  to  network  device  driver  to  send) 

(wait  until  message  sent) 

return 
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